Most data processing and computer systems provide interaction with a user in only one natural language, such as English, French or German. Such natural languages are those used in speech by individuals and are distinct from computer programming languages. Due to the international context in which computers increasingly are being used, a need has arisen for data processing systems which interact with users in any of multiple natural languages, or "interaction languages".
In most data processing systems, interaction with a user involves sending and receiving messages between the user and the data processing system. To facilitate such message sending and receiving, a data processing system normally has standard instructions for sending output messages to the user and also has similar instructions for interpreting input messages received from the user. An application programmer uses these instructions in an application program in order to provide interaction between a user and the data processing system when the program is run, i.e., when the system is configured by the program and processes described by the program are executed by the configured system.
A well-known technique for sending and receiving messages involves placing output and input messages for an application program in a file or in a location separate from the application program. Such messages are referenced by the application program via codes or indices. This technique is known as "externalizing". The application program occasionally retains messages, i.e., which are not externalized, for use as default messages, for example. These messages are sometimes referred to as "hard-coded."
When an application program and corresponding externalized message file are employed in a system, a link is created, at run time, between the application program and the message file. This link specifies that the message file is to be used in conjunction with the application program to provide output and input messages for the program. In current systems, either a user or the application programmer has to explicitly specify the message file which is to be used with the application program. Hence, the link is not transparent to the programmer, and the application programmer as well as the user must know the names of available message files. In a system which supports multiple interaction languages, multiple message files are needed, thus complicating the burden on the programmer and the user.
A current multi-lingual system which adapts an "externalizing" approach, is the Native Language System (NLS). NLS is a system interface developed by X/OPEN which is a joint initiative by members of the business community to integrate evolving standards into a common, beneficial and continuing strategy. The system interface is a set of commands available for use in application programs to configure and manipulate a data processing system. Many implementations for supporting the NLS interface exist, but each implementation shares the functionality defined by X/OPEN in its Portability Guide, (1989), (note especially volume 2).
In NLS, each externalized message file for an application program containing output and input messages in an interaction language is identified by a string name known as a "catalog descriptor". With NLS an application programmer needs to know the catalog descriptor for a message file in order to load the message file into memory, and to retrieve messages from it. The catalog descriptor may be constructed from a default value, such as a system-wide default or a per-user default. In NLS, the user default value overrides the system default and may be used to override the default for an application program. No nesting capability is provided. If a message file in a desired language is not available for an application program, the user normally receives hard-coded messages of the application program. Because the application programmer uses the name of the message file in the application program, and also handles the opening and closing of message files, problems arise in the development of application programs.
A first problem with the NLS system is the required involvement of the application programmer in the management of message files. Periodically, message files for an application program are modified, or new message files are added for use by the application program. Such modifications and additions may require changes to application programs that reference the modified or additional message files. As a result, when such message files are provided to a customer, the application program must be updated as well, hence increasing both manufacturing costs to the application program supplier and material costs to the customer.
A second difficulty of the NLS system is that it requires an application programmer to develop a program for handling instances where a message file is not found during attempts to open the file or to retrieve a message from the file. Typically, such a program provides a hard-coded default message for use when a message or message file is not found. However, such default messages are provided solely at the discretion of the application programmer. As such, application programs produced by different application programmers may not have uniform default mechanisms. Thus, such application programs are not consistent in this respect.
Multi-lingual interaction in NLS is also not transparent to the user. For example, the user may be asked to select an interaction language. However, this capability is provided only at the discretion of the application programmer, and thus may not be consistent. This lack of a consistent mechanism for selecting an interaction language may be confusing both to the user and to the application programmer. Furthermore, a user often has to specify a desired interaction language more than once when using layered processes. Such inconsistent systems are inconvenient and annoying to use and maintain.
Finally, due in part to the lack of transparency and consistency, these systems fail to make use of the "nesting" capability of a system. That is, when an application program runs another application program (i.e., it makes a "nested" call), interaction language information is not "nested". A user also is not able to specify different languages for different program levels.
Application libraries are commonly used in large multi-user systems and contain common subroutines accessed by a number of application programs. Access to these application libraries often involves a kind of nested call. Without the provision of multi-lingual support for nested application programs or libraries, message handling for application libraries may be inconsistent or even unpredictable.
Accordingly, it is an object of the present invention to provide a data processing system and method capable of supporting user interaction in any of multiple natural languages in a manner that is transparent both to the user and to the application programmer.
It is another object of the present invention to provide a data processing system wherein the management of message files is transparent to the application programmer.
It is another object of the present invention to provide a data processing system that links a message file to an application program or library without user interaction.
It is still another object of the present invention to provide a data processing system which may support nested calls in different interaction languages.